\chapter{Probleemstelling}
\label{Probleemstelling}
In dit stuk wordt er verduidelijkt hoe er misbruik gemaakt kan worden van deze mashups door een aanvaller. 
Gevolgd door de toenemende impact dat de onveilige mashups hebben, door de nieuwe set functionaliteiten die HTML5 aanbiedt. 
Dit zal als leidraad dienen voor de doelstellingen van de thesis, die op het einde van dit hoofdstuk worden beschreven.

\section{Aanvaller model}
Zowel de client als de integrator zijn betrouwbare actoren, als aanvaller beschouwen we de "third-party component". 
We stellen dat de integrator een pagina beheert met meerdere mashup componenten. 
De opzet van de aanvaller bestaat er dan in om deze component in de pagina van de integrator te krijgen. 
Dit kan bijvoorbeeld door het aanbieden van zijn component aan de integrator (e.g. valse reclame of een valse kopie van een bestaande component). 
Een tweede manier zou zijn door zichzelf in een bestaande third-party component te hacken, waarbij de integrator de bestaande component vertrouwd.

\pagebreak

\section{Gevoelige JavaScript Operaties}
Als de aanvaller JavaScript code kan uitvoeren in een onveilige mashup, dan heeft deze dezelfde mogelijkheden als met een \emph{cross-site scripting} aanval(XSS).
Of in de origin van de component, of in de origin van de integrator. Typische gevoelige operaties zoals het opvragen van cookies, 
doorverwijzen naar een andere pagina, lezen en/of aanpassen van de Document Object Model (DOM) zijn dan mogelijk. 

Bovendien zijn de aanvalsmogelijkheden nog verder uitgebreid, met de komst van de nieuwe HTML5-specificaties\cite{intohtmlv}.
Zo is het mogelijk om via JavaScript o.a. de geolocation van de gebruiker te raadplegen, audio en video op te nemen, 
data op te slaan en op te halen aan de client-side, te communiceren met verschillende windows en zelfs met externe servers.
Dit maakt het uitvoeren van een potenti\"ele aanval nog interessanter, zelfs als het script beperkt is tot het uitvoeren binnen zijn eigen origin.

\section{Least-privilege integration}
In onveilige composities is er nood aan een beperking van de mogelijkheden van elke mashup component,
gezien de mogelijke aanvallen. Het zou optimaal zijn elke mashup component te integreren volgens het least-privilege principe.
Dit wil zeggen dat elke component enkel deze functionaliteiten ter beschikking heeft, die nodig zijn om zijn taken te kunnen vervullen. 
Stel als voorbeeld IGoogle (zie fig \ref{igoogle}), de gebruiker kan hier zelf componenten aan toevoegen. 
In dit voorbeeld heeft een persoon op zijn pagina componenten toegevoegd voor zijn emails en docs te bekijken. 
Maar ook het weerbericht en het laatste nieuws is te vinden op deze pagina. 
Het zou bijvoorbeeld geen nut hebben cookies toe te laten voor deze laatste twee componenten. 
Deze zouden bijvoorbeeld wel gebruik kunnen maken van \lstinline|XMLHttpRequest| om nieuwe data binnen te halen.
\begin{figure}
	\centering
 	\includegraphics[width=0.90\textwidth]{img/igoogle.jpg}
 	\caption{Voorbeeld web mashup: IGoogle  \textit{(http://www.google.com/ig/})}
 	\label{igoogle}
\end{figure}

Helaas is least-privilege integration nog niet mogelijk met de huidige script inclusion en iframe integration technieken.
Deze technieken(zie sectie \ref{curstateofprac}) zijn te algemeen, ofwel zijn er geen restricties ofwel beperkt door de same-origin policy.

\pagebreak

\section{Doelstellingen}
Er is nood aan een veilige architectuur die least-privilege integration ondersteunt voor web componenten. 
De architectuur moet veilig zijn, in de zin dat een aanvaller het mechanisme niet kan omzeilen.
Binnen deze architectuur moet het mogelijk zijn functies af te schermen, en daarmee ook alle paden naar dezelfde functionaliteiten.
Het afschermen van functionaliteiten moet kunnen worden beschreven in een policy taal. Eventueel gegroepeerd per categorie.
De architectuur zou volgende doelstellingen moeten behalen.

\begin{description}
	\item[D1 Volledige afscherming] Het moet mogelijk zijn functies af te schermen, en daarmee ook alle paden naar dezelfde functionaliteiten.
	\item[D2 Geen aanpassingen aan de componenten] Het moet mogelijk zijn om de componenten te integreren zonder dat daarvoor hun code moet herschreven worden.
	\item[D3 Security policy] Het moet mogelijk zijn voor de mashup integrator om policies op te leggen op de code van de externe componenten.
	\item[D4 Geen client-side aanpassingen] De architectuur zou ten opzichte van de client onzichtbaar moeten zijn. Iedere client die de mashup bezoekt zou automatisch beschermd moeten worden, zonder dat die eerst een addon moet installeren of andere browser aanpassingen moet doorvoeren.
\end{description}

